<!DOCTYPE html>
<html lang="en-us">
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
    
<meta charset="UTF-8">
<title>Tune for search speed | Elasticsearch Guide [7.7] | Elastic</title>
<link rel="home" href="index.html" title="Elasticsearch Guide [7.7]">
<link rel="up" href="how-to.html" title="How To">
<link rel="prev" href="tune-for-indexing-speed.html" title="Tune for indexing speed">
<link rel="next" href="_tune_your_queries_with_the_profile_api.html" title="Tune your queries with the Profile API">
<meta name="DC.type" content="Learn/Docs/Elasticsearch/Reference/7.7">
<meta name="DC.subject" content="Elasticsearch">
<meta name="DC.identifier" content="7.7">
<meta name="robots" content="noindex,nofollow">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <script src="https://cdn.optimizely.com/js/18132920325.js"></script>
    <link rel="apple-touch-icon" sizes="57x57" href="/apple-icon-57x57.png">
    <link rel="apple-touch-icon" sizes="60x60" href="/apple-icon-60x60.png">
    <link rel="apple-touch-icon" sizes="72x72" href="/apple-icon-72x72.png">
    <link rel="apple-touch-icon" sizes="76x76" href="/apple-icon-76x76.png">
    <link rel="apple-touch-icon" sizes="114x114" href="/apple-icon-114x114.png">
    <link rel="apple-touch-icon" sizes="120x120" href="/apple-icon-120x120.png">
    <link rel="apple-touch-icon" sizes="144x144" href="/apple-icon-144x144.png">
    <link rel="apple-touch-icon" sizes="152x152" href="/apple-icon-152x152.png">
    <link rel="apple-touch-icon" sizes="180x180" href="/apple-icon-180x180.png">
    <link rel="icon" type="image/png" href="/favicon-32x32.png" sizes="32x32">
    <link rel="icon" type="image/png" href="/android-chrome-192x192.png" sizes="192x192">
    <link rel="icon" type="image/png" href="/favicon-96x96.png" sizes="96x96">
    <link rel="icon" type="image/png" href="/favicon-16x16.png" sizes="16x16">
    <link rel="manifest" href="/manifest.json">
    <meta name="apple-mobile-web-app-title" content="Elastic">
    <meta name="application-name" content="Elastic">
    <meta name="msapplication-TileColor" content="#ffffff">
    <meta name="msapplication-TileImage" content="/mstile-144x144.png">
    <meta name="theme-color" content="#ffffff">
    <meta name="naver-site-verification" content="936882c1853b701b3cef3721758d80535413dbfd">
    <meta name="yandex-verification" content="d8a47e95d0972434">
    <meta name="localized" content="true">
    <meta name="st:robots" content="follow,index">
    <meta property="og:image" content="https://www.elastic.co/static/images/elastic-logo-200.png">
    <link rel="shortcut icon" href="/favicon.ico" type="image/x-icon">
    <link rel="icon" href="/favicon.ico" type="image/x-icon">
    <link rel="apple-touch-icon-precomposed" sizes="64x64" href="/favicon_64x64_16bit.png">
    <link rel="apple-touch-icon-precomposed" sizes="32x32" href="/favicon_32x32.png">
    <link rel="apple-touch-icon-precomposed" sizes="16x16" href="/favicon_16x16.png">
    <!-- Give IE8 a fighting chance -->
    <!--[if lt IE 9]>
    <script src="https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js"></script>
    <script src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js"></script>
    <![endif]-->
    <link rel="stylesheet" type="text/css" href="/guide/static/styles.css">
  </head>

  <!--© 2015-2021 Elasticsearch B.V. Copying, publishing and/or distributing without written permission is strictly prohibited.-->

  <body>
    <!-- Google Tag Manager -->
    <script>dataLayer = [];</script><noscript><iframe src="//www.googletagmanager.com/ns.html?id=GTM-58RLH5" height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>
    <script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start': new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0], j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src= '//www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f); })(window,document,'script','dataLayer','GTM-58RLH5');</script>
    <!-- End Google Tag Manager -->

    <!-- Global site tag (gtag.js) - Google Analytics -->
    <script async src="https://www.googletagmanager.com/gtag/js?id=UA-12395217-16"></script>
    <script>
      window.dataLayer = window.dataLayer || [];
      function gtag(){dataLayer.push(arguments);}
      gtag('js', new Date());
      gtag('config', 'UA-12395217-16');
    </script>

    <!--BEGIN QUALTRICS WEBSITE FEEDBACK SNIPPET-->
    <script type="text/javascript">
      (function(){var g=function(e,h,f,g){
      this.get=function(a){for(var a=a+"=",c=document.cookie.split(";"),b=0,e=c.length;b<e;b++){for(var d=c[b];" "==d.charAt(0);)d=d.substring(1,d.length);if(0==d.indexOf(a))return d.substring(a.length,d.length)}return null};
      this.set=function(a,c){var b="",b=new Date;b.setTime(b.getTime()+6048E5);b="; expires="+b.toGMTString();document.cookie=a+"="+c+b+"; path=/; "};
      this.check=function(){var a=this.get(f);if(a)a=a.split(":");else if(100!=e)"v"==h&&(e=Math.random()>=e/100?0:100),a=[h,e,0],this.set(f,a.join(":"));else return!0;var c=a[1];if(100==c)return!0;switch(a[0]){case "v":return!1;case "r":return c=a[2]%Math.floor(100/c),a[2]++,this.set(f,a.join(":")),!c}return!0};
      this.go=function(){if(this.check()){var a=document.createElement("script");a.type="text/javascript";a.src=g;document.body&&document.body.appendChild(a)}};
      this.start=function(){var a=this;window.addEventListener?window.addEventListener("load",function(){a.go()},!1):window.attachEvent&&window.attachEvent("onload",function(){a.go()})}};
      try{(new g(100,"r","QSI_S_ZN_emkP0oSe9Qrn7kF","https://znemkp0ose9qrn7kf-elastic.siteintercept.qualtrics.com/WRSiteInterceptEngine/?Q_ZID=ZN_emkP0oSe9Qrn7kF")).start()}catch(i){}})();
    </script><div id="ZN_emkP0oSe9Qrn7kF"><!--DO NOT REMOVE-CONTENTS PLACED HERE--></div>
    <!--END WEBSITE FEEDBACK SNIPPET-->

    <div id="elastic-nav" style="display:none;"></div>
    <script src="https://www.elastic.co/elastic-nav.js"></script>

    <!-- Subnav -->
    <div>
      <div>
        <div class="tertiary-nav d-none d-md-block">
          <div class="container">
            <div class="p-t-b-15 d-flex justify-content-between nav-container">
              <div class="breadcrum-wrapper"><span><a href="/guide/" style="font-size: 14px; font-weight: 600; color: #000;">Docs</a></span></div>
            </div>
          </div>
        </div>
      </div>
    </div>

    <div class="main-container">
      <section id="content">
        <div class="content-wrapper">

          <section id="guide" lang="en">
            <div class="container">
              <div class="row">
                <div class="col-xs-12 col-sm-8 col-md-8 guide-section">
                  <!-- start body -->
                  <div class="page_header">
<strong>IMPORTANT</strong>: No additional bug fixes or documentation updates
will be released for this version. For the latest information, see the
<a href="../current/index.html">current release documentation</a>.
</div>
<div id="content">
<div class="breadcrumbs">
<span class="breadcrumb-link"><a href="index.html">Elasticsearch Guide [7.7]</a></span>
»
<span class="breadcrumb-link"><a href="how-to.html">How To</a></span>
»
<span class="breadcrumb-node">Tune for search speed</span>
</div>
<div class="navheader">
<span class="prev">
<a href="tune-for-indexing-speed.html">« Tune for indexing speed</a>
</span>
<span class="next">
<a href="_tune_your_queries_with_the_profile_api.html">Tune your queries with the Profile API »</a>
</span>
</div>
<div class="chapter">
<div class="titlepage"><div><div>
<h2 class="title">
<a id="tune-for-search-speed"></a>Tune for search speed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/how-to/search-speed.asciidoc">edit</a>
</h2>
</div></div></div>
<h3>
<a id="_give_memory_to_the_filesystem_cache_2"></a>Give memory to the filesystem cache<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/how-to/search-speed.asciidoc">edit</a>
</h3>
<p>Elasticsearch heavily relies on the filesystem cache in order to make search
fast. In general, you should make sure that at least half the available memory
goes to the filesystem cache so that Elasticsearch can keep hot regions of the
index in physical memory.</p>
<h3>
<a id="_use_faster_hardware_2"></a>Use faster hardware<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/how-to/search-speed.asciidoc">edit</a>
</h3>
<p>If your search is I/O bound, you should investigate giving more memory to the
filesystem cache (see above) or buying faster drives. In particular SSD drives
are known to perform better than spinning disks. Always use local storage,
remote filesystems such as <code class="literal">NFS</code> or <code class="literal">SMB</code> should be avoided. Also beware of
virtualized storage such as Amazon’s <code class="literal">Elastic Block Storage</code>. Virtualized
storage works very well with Elasticsearch, and it is appealing since it is so
fast and simple to set up, but it is also unfortunately inherently slower on an
ongoing basis when compared to dedicated local storage. If you put an index on
<code class="literal">EBS</code>, be sure to use provisioned IOPS otherwise operations could be quickly
throttled.</p>
<p>If your search is CPU-bound, you should investigate buying faster CPUs.</p>
<h3>
<a id="_document_modeling"></a>Document modeling<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/how-to/search-speed.asciidoc">edit</a>
</h3>
<p>Documents should be modeled so that search-time operations are as cheap as possible.</p>
<p>In particular, joins should be avoided. <a class="xref" href="nested.html" title="Nested datatype"><code class="literal">nested</code></a> can make queries
several times slower and <a class="xref" href="parent-join.html" title="Join datatype">parent-child</a> relations can make
queries hundreds of times slower. So if the same questions can be answered without
joins by denormalizing documents, significant speedups can be expected.</p>
<h3>
<a id="_search_as_few_fields_as_possible"></a>Search as few fields as possible<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/how-to/search-speed.asciidoc">edit</a>
</h3>
<p>The more fields a <a class="xref" href="query-dsl-query-string-query.html" title="Query string query"><code class="literal">query_string</code></a> or
<a class="xref" href="query-dsl-multi-match-query.html" title="Multi-match query"><code class="literal">multi_match</code></a> query targets, the slower it is.
A common technique to improve search speed over multiple fields is to copy
their values into a single field at index time, and then use this field at
search time. This can be automated with the <a class="xref" href="copy-to.html" title="copy_to"><code class="literal">copy-to</code></a> directive of
mappings without having to change the source of documents. Here is an example
of an index containing movies that optimizes queries that search over both the
name and the plot of the movie by indexing both values into the <code class="literal">name_and_plot</code>
field.</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">PUT movies
{
  "mappings": {
    "properties": {
      "name_and_plot": {
        "type": "text"
      },
      "name": {
        "type": "text",
        "copy_to": "name_and_plot"
      },
      "plot": {
        "type": "text",
        "copy_to": "name_and_plot"
      }
    }
  }
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/1307.console"></div>
<h3>
<a id="_pre_index_data"></a>Pre-index data<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/how-to/search-speed.asciidoc">edit</a>
</h3>
<p>You should leverage patterns in your queries to optimize the way data is indexed.
For instance, if all your documents have a <code class="literal">price</code> field and most queries run
<a class="xref" href="search-aggregations-bucket-range-aggregation.html" title="Range Aggregation"><code class="literal">range</code></a> aggregations on a fixed
list of ranges, you could make this aggregation faster by pre-indexing the ranges
into the index and using a <a class="xref" href="search-aggregations-bucket-terms-aggregation.html" title="Terms Aggregation"><code class="literal">terms</code></a>
aggregations.</p>
<p>For instance, if documents look like:</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">PUT index/_doc/1
{
  "designation": "spoon",
  "price": 13
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/1308.console"></div>
<p>and search requests look like:</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">GET index/_search
{
  "aggs": {
    "price_ranges": {
      "range": {
        "field": "price",
        "ranges": [
          { "to": 10 },
          { "from": 10, "to": 100 },
          { "from": 100 }
        ]
      }
    }
  }
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/1309.console"></div>
<p>Then documents could be enriched by a <code class="literal">price_range</code> field at index time, which
should be mapped as a <a class="xref" href="keyword.html" title="Keyword datatype"><code class="literal">keyword</code></a>:</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">PUT index
{
  "mappings": {
    "properties": {
      "price_range": {
        "type": "keyword"
      }
    }
  }
}

PUT index/_doc/1
{
  "designation": "spoon",
  "price": 13,
  "price_range": "10-100"
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/1310.console"></div>
<p>And then search requests could aggregate this new field rather than running a
<code class="literal">range</code> aggregation on the <code class="literal">price</code> field.</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">GET index/_search
{
  "aggs": {
    "price_ranges": {
      "terms": {
        "field": "price_range"
      }
    }
  }
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/1311.console"></div>
<h3>
<a id="map-ids-as-keyword"></a>Consider mapping identifiers as <code class="literal">keyword</code><a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/how-to/search-speed.asciidoc">edit</a>
</h3>
<p>Not all numeric data should be mapped as a <a class="xref" href="number.html" title="Numeric datatypes">numeric</a> field datatype.
Elasticsearch optimizes numeric fields, such as <code class="literal">integer</code> or <code class="literal">long</code>, for
<a class="xref" href="query-dsl-range-query.html" title="Range query"><code class="literal">range</code></a> queries. However, <a class="xref" href="keyword.html" title="Keyword datatype"><code class="literal">keyword</code></a> fields
are better for <a class="xref" href="query-dsl-term-query.html" title="Term query"><code class="literal">term</code></a> and other
<a class="xref" href="term-level-queries.html" title="Term-level queries">term-level</a> queries.</p>
<p>Identifiers, such as an ISBN or a product ID, are rarely used in <code class="literal">range</code>
queries. However, they are often retrieved using term-level queries.</p>
<p>Consider mapping a numeric identifier as a <code class="literal">keyword</code> if:</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
You don’t plan to search for the identifier data using
<a class="xref" href="query-dsl-range-query.html" title="Range query"><code class="literal">range</code></a> queries.
</li>
<li class="listitem">
Fast retrieval is important. <code class="literal">term</code> query searches on <code class="literal">keyword</code> fields are
often faster than <code class="literal">term</code> searches on numeric fields.
</li>
</ul>
</div>
<p>If you’re unsure which to use, you can use a <a class="xref" href="multi-fields.html" title="fields">multi-field</a> to map
the data as both a <code class="literal">keyword</code> <em>and</em> a numeric datatype.</p>
<h3>
<a id="_avoid_scripts"></a>Avoid scripts<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/how-to/search-speed.asciidoc">edit</a>
</h3>
<p>If possible, avoid using <a class="xref" href="modules-scripting.html" title="Scripting">scripts</a> or
<a class="xref" href="search-request-body.html#request-body-search-script-fields" title="Script Fields">scripted fields</a> in searches. Because
scripts can’t make use of index structures, using scripts in search queries can
result in slower search speeds.</p>
<p>If you often use scripts to transform indexed data, you can speed up search by
making these changes during ingest instead. However, that often means slower
index speeds.</p>
<details>
<summary class="title"><span class="strong strong"><strong>Example</strong></span></summary>
<div class="content">
<p>An index, <code class="literal">my_test_scores</code>, contains two <code class="literal">long</code> fields:</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
<code class="literal">math_score</code>
</li>
<li class="listitem">
<code class="literal">verbal_score</code>
</li>
</ul>
</div>
<p>When running searches, users often use a script to sort results by the sum of
these two field’s values.</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">GET /my_test_scores/_search
{
  "query": {
    "term": {
      "grad_year": "2020"
    }
  },
  "sort": [
    {
      "_script": {
        "type": "number",
        "script": {
          "source": "doc['math_score'].value + doc['verbal_score'].value"
        },
        "order": "desc"
      }
    }
  ]
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/1312.console"></div>
<p>To speed up search, you can perform this calculation during ingest and index the
sum to a field instead.</p>
<p>First, <a class="xref" href="indices-put-mapping.html" title="Put mapping API">add a new field</a>, <code class="literal">total_score</code>, to the index. The
<code class="literal">total_score</code> field will contain sum of the <code class="literal">math_score</code> and <code class="literal">verbal_score</code>
field values.</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">PUT /my_test_scores/_mapping
{
  "properties": {
    "total_score": {
      "type": "long"
    }
  }
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/1313.console"></div>
<p>Next, use an <a class="xref" href="ingest.html" title="Ingest node">ingest pipeline</a> containing the
<a class="xref" href="script-processor.html" title="Script Processor"><code class="literal">script</code></a> processor to calculate the sum of <code class="literal">math_score</code> and
<code class="literal">verbal_score</code> and index it in the <code class="literal">total_score</code> field.</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">PUT _ingest/pipeline/my_test_scores_pipeline
{
  "description": "Calculates the total test score",
  "processors": [
    {
      "script": {
        "source": "ctx.total_score = (ctx.math_score + ctx.verbal_score)"
      }
    }
  ]
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/1314.console"></div>
<p>To update existing data, use this pipeline to <a class="xref" href="docs-reindex.html" title="Reindex API">reindex</a> any
documents from <code class="literal">my_test_scores</code> to a new index, <code class="literal">my_test_scores_2</code>.</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">POST /_reindex
{
  "source": {
    "index": "my_test_scores"
  },
  "dest": {
    "index": "my_test_scores_2",
    "pipeline": "my_test_scores_pipeline"
  }
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/1315.console"></div>
<p>Continue using the pipeline to index any new documents to <code class="literal">my_test_scores_2</code>.</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">POST /my_test_scores_2/_doc/?pipeline=my_test_scores_pipeline
{
  "student": "kimchy",
  "grad_year": "2020",
  "math_score": 800,
  "verbal_score": 800
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/1316.console"></div>
<p>These changes may slow indexing but allow for faster searches. Users can now
sort searches made on <code class="literal">my_test_scores_2</code> using the <code class="literal">total_score</code> field instead
of using a script.</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">GET /my_test_scores_2/_search
{
  "query": {
    "term": {
      "grad_year": "2020"
    }
  },
  "sort": [
    {
      "total_score": {
        "order": "desc"
      }
    }
  ]
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/1317.console"></div>
</div>
</details>
<p>We recommend testing and benchmarking any indexing changes before deploying them
in production.</p>
<h3>
<a id="_search_rounded_dates"></a>Search rounded dates<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/how-to/search-speed.asciidoc">edit</a>
</h3>
<p>Queries on date fields that use <code class="literal">now</code> are typically not cacheable since the
range that is being matched changes all the time. However switching to a
rounded date is often acceptable in terms of user experience, and has the
benefit of making better use of the query cache.</p>
<p>For instance the below query:</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">PUT index/_doc/1
{
  "my_date": "2016-05-11T16:30:55.328Z"
}

GET index/_search
{
  "query": {
    "constant_score": {
      "filter": {
        "range": {
          "my_date": {
            "gte": "now-1h",
            "lte": "now"
          }
        }
      }
    }
  }
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/1318.console"></div>
<p>could be replaced with the following query:</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">GET index/_search
{
  "query": {
    "constant_score": {
      "filter": {
        "range": {
          "my_date": {
            "gte": "now-1h/m",
            "lte": "now/m"
          }
        }
      }
    }
  }
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/1319.console"></div>
<p>In that case we rounded to the minute, so if the current time is <code class="literal">16:31:29</code>,
the range query will match everything whose value of the <code class="literal">my_date</code> field is
between <code class="literal">15:31:00</code> and <code class="literal">16:31:59</code>. And if several users run a query that
contains this range in the same minute, the query cache could help speed things
up a bit. The longer the interval that is used for rounding, the more the query
cache can help, but beware that too aggressive rounding might also hurt user
experience.</p>
<div class="note admon">
<div class="icon"></div>
<div class="admon_content">
<p>It might be tempting to split ranges into a large cacheable part and
smaller not cacheable parts in order to be able to leverage the query cache,
as shown below:</p>
</div>
</div>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">GET index/_search
{
  "query": {
    "constant_score": {
      "filter": {
        "bool": {
          "should": [
            {
              "range": {
                "my_date": {
                  "gte": "now-1h",
                  "lte": "now-1h/m"
                }
              }
            },
            {
              "range": {
                "my_date": {
                  "gt": "now-1h/m",
                  "lt": "now/m"
                }
              }
            },
            {
              "range": {
                "my_date": {
                  "gte": "now/m",
                  "lte": "now"
                }
              }
            }
          ]
        }
      }
    }
  }
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/1320.console"></div>
<p>However such practice might make the query run slower in some cases since the
overhead introduced by the <code class="literal">bool</code> query may defeat the savings from better
leveraging the query cache.</p>
<h3>
<a id="_force_merge_read_only_indices"></a>Force-merge read-only indices<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/how-to/search-speed.asciidoc">edit</a>
</h3>
<p>Indices that are read-only may benefit from being <a class="xref" href="indices-forcemerge.html" title="Force merge API">merged
down to a single segment</a>. This is typically the case with time-based indices:
only the index for the current time frame is getting new documents while older
indices are read-only. Shards that have been force-merged into a single segment
can use simpler and more efficient data structures to perform searches.</p>
<div class="important admon">
<div class="icon"></div>
<div class="admon_content">
<p>Do not force-merge indices to which you are still writing, or to
which you will write again in the future. Instead, rely on the automatic
background merge process to perform merges as needed to keep the index running
smoothly. If you continue to write to a force-merged index then its performance
may become much worse.</p>
</div>
</div>
<h3>
<a id="_warm_up_global_ordinals"></a>Warm up global ordinals<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/how-to/search-speed.asciidoc">edit</a>
</h3>
<p>Global ordinals are a data-structure that is used in order to run
<a class="xref" href="search-aggregations-bucket-terms-aggregation.html" title="Terms Aggregation"><code class="literal">terms</code></a> aggregations on
<a class="xref" href="keyword.html" title="Keyword datatype"><code class="literal">keyword</code></a> fields. They are loaded lazily in memory because
Elasticsearch does not know which fields will be used in <code class="literal">terms</code> aggregations
and which fields won’t. You can tell Elasticsearch to load global ordinals
eagerly when starting or refreshing a shard by configuring mappings as
described below:</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">PUT index
{
  "mappings": {
    "properties": {
      "foo": {
        "type": "keyword",
        "eager_global_ordinals": true
      }
    }
  }
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/1321.console"></div>
<h3>
<a id="_warm_up_the_filesystem_cache"></a>Warm up the filesystem cache<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/how-to/search-speed.asciidoc">edit</a>
</h3>
<p>If the machine running Elasticsearch is restarted, the filesystem cache will be
empty, so it will take some time before the operating system loads hot regions
of the index into memory so that search operations are fast. You can explicitly
tell the operating system which files should be loaded into memory eagerly
depending on the file extension using the
<a class="xref" href="preload-data-to-file-system-cache.html" title="Preloading data into the file system cache"><code class="literal">index.store.preload</code></a> setting.</p>
<div class="warning admon">
<div class="icon"></div>
<div class="admon_content">
<p>Loading data into the filesystem cache eagerly on too many indices or
too many files will make search <em>slower</em> if the filesystem cache is not large
enough to hold all the data. Use with caution.</p>
</div>
</div>
<h3>
<a id="_use_index_sorting_to_speed_up_conjunctions"></a>Use index sorting to speed up conjunctions<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/how-to/search-speed.asciidoc">edit</a>
</h3>
<p><a class="xref" href="index-modules-index-sorting.html" title="Index Sorting">Index sorting</a> can be useful in order to make
conjunctions faster at the cost of slightly slower indexing. Read more about it
in the <a class="xref" href="index-modules-index-sorting-conjunctions.html" title="Use index sorting to speed up conjunctions">index sorting documentation</a>.</p>
<h3>
<a id="preference-cache-optimization"></a>Use <code class="literal">preference</code> to optimize cache utilization<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/how-to/search-speed.asciidoc">edit</a>
</h3>
<p>There are multiple caches that can help with search performance, such as the
<a href="https://en.wikipedia.org/wiki/Page_cache" class="ulink" target="_top">filesystem cache</a>, the
<a class="xref" href="shard-request-cache.html" title="Shard request cache settings">request cache</a> or the <a class="xref" href="query-cache.html" title="Node query cache settings">query cache</a>. Yet
all these caches are maintained at the node level, meaning that if you run the
same request twice in a row, have 1 <a class="xref" href="glossary.html#glossary-replica-shard">replica</a> or more
and use <a href="https://en.wikipedia.org/wiki/Round-robin_DNS" class="ulink" target="_top">round-robin</a>, the default
routing algorithm, then those two requests will go to different shard copies,
preventing node-level caches from helping.</p>
<p>Since it is common for users of a search application to run similar requests
one after another, for instance in order to analyze a narrower subset of the
index, using a preference value that identifies the current user or session
could help optimize usage of the caches.</p>
<h3>
<a id="_replicas_might_help_with_throughput_but_not_always"></a>Replicas might help with throughput, but not always<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/how-to/search-speed.asciidoc">edit</a>
</h3>
<p>In addition to improving resiliency, replicas can help improve throughput. For
instance if you have a single-shard index and three nodes, you will need to
set the number of replicas to 2 in order to have 3 copies of your shard in
total so that all nodes are utilized.</p>
<p>Now imagine that you have a 2-shards index and two nodes. In one case, the
number of replicas is 0, meaning that each node holds a single shard. In the
second case the number of replicas is 1, meaning that each node has two shards.
Which setup is going to perform best in terms of search performance? Usually,
the setup that has fewer shards per node in total will perform better. The
reason for that is that it gives a greater share of the available filesystem
cache to each shard, and the filesystem cache is probably Elasticsearch’s
number 1 performance factor. At the same time, beware that a setup that does
not have replicas is subject to failure in case of a single node failure, so
there is a trade-off between throughput and availability.</p>
<p>So what is the right number of replicas? If you have a cluster that has
<code class="literal">num_nodes</code> nodes, <code class="literal">num_primaries</code> primary shards <em>in total</em> and if you want to
be able to cope with <code class="literal">max_failures</code> node failures at once at most, then the
right number of replicas for you is
<code class="literal">max(max_failures, ceil(num_nodes / num_primaries) - 1)</code>.</p>




</div>
<div class="navfooter">
<span class="prev">
<a href="tune-for-indexing-speed.html">« Tune for indexing speed</a>
</span>
<span class="next">
<a href="_tune_your_queries_with_the_profile_api.html">Tune your queries with the Profile API »</a>
</span>
</div>
</div>

                  <!-- end body -->
                </div>
                <div class="col-xs-12 col-sm-4 col-md-4" id="right_col">
                  <div id="rtpcontainer" style="display: block;">
                    <div class="mktg-promo">
                      <h3>Most Popular</h3>
                      <ul class="icons">
                        <li class="icon-elasticsearch-white"><a href="https://www.elastic.co/webinars/getting-started-elasticsearch?baymax=default&amp;elektra=docs&amp;storm=top-video">Get Started with Elasticsearch: Video</a></li>
                        <li class="icon-kibana-white"><a href="https://www.elastic.co/webinars/getting-started-kibana?baymax=default&amp;elektra=docs&amp;storm=top-video">Intro to Kibana: Video</a></li>
                        <li class="icon-logstash-white"><a href="https://www.elastic.co/webinars/introduction-elk-stack?baymax=default&amp;elektra=docs&amp;storm=top-video">ELK for Logs &amp; Metrics: Video</a></li>
                      </ul>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </section>

        </div>


<div id="elastic-footer"></div>
<script src="https://www.elastic.co/elastic-footer.js"></script>
<!-- Footer Section end-->

      </section>
    </div>

<script src="/guide/static/jquery.js"></script>
<script type="text/javascript" src="/guide/static/docs.js"></script>
<script type="text/javascript">
  window.initial_state = {}</script>
  </body>
</html>
